Let's not be too hasty, as I said will follow up with OSS CELA on the actual requirements ASAP

CELA conclusion: we can only run enhanced license scan on specific versions we use, so this idea could work.

By "this idea" do you mean the VERSIONS file? How would that work from a consumer's perspective, specifically re: legal? (Feel free to respond on teams if needed.)

My initial idea was that we can implement a Webpack plugin that will ensure that included dependencies match versions defined in VERSIONS file.

If we will use a caret ("lodash": "^4.17.20") only a single version (a latest in a range) will be installed

Just a heads up, this is not necessarily true--if a dep on lodash@^4.17.20 resolved to 4.17.20 already exists in the lockfile, and that semver spec is still referenced by another package, yarn may add a separate entry for lodash@^4.17.21 => 4.17.21 instead of resolving both to 4.17.21.

(Doesn't affect the proposal since this is an issue with yarn in general, but I wanted to call it out for awareness.)

Yeah, you're totally right 👍 But with ranges we can at least deduplicate dependencies manually or via tools (yarn-deduplicate for Yarn v1 or yarn dedupe for V2).

A couple possible issues/nuances here that I wonder if we should include in the proposal re: different versions for production and dev dependencies:

1. How do we set this up with syncpack? My first idea would be something like this (supposing converged1 and converged2 depend on lodash@^4.17.21, whereas other packages have a specific version in devDependencies):

{
  "packages": ["@fluentui/converged1", "@fluentui/converged2"],
  "dependencies": ["lodash"]
}

2. How do we guarantee that yarn resolves the production dep to the same version as the dev dep within our repo? Without tooling enforcement, it's entirely possible that yarn could choose to resolve the two versions differently. My first idea (which probably won't work, see below) is this. (The leading ** is necessary to make resolutions work for packages within the workspace.)

{
  "resolutions": {
    "**/@fluentui/*/lodash": "4.17.21"
  }
}

However this might not work because the resolutions spec says a single * is not supported (would probably be good to test it in case the implementation is different). **/@fluentui/**/lodash should be supported, but that would resolve all nested tools' lodash deps to a specific version, which might be a problem. So we'd probably have to figure out some other approach.

How do we set this up with syncpack?

Do you mean our repo, correct? Can please expand a bit more there, I did not get the problem.

How do we guarantee that yarn resolves the production dep to the same version as the dev dep within our repo?

IMO we should not guarantee this, for example: we don't restrict people to use the same version of React as in our repo, why it should be different for other dependencies? It means that we should be accurate in choosing dependencies, they should follow semver.

However, resolutions can be and should be used by customers for legal issues. I tried your approach with resolutions on Yarn v1:

{
  "dependencies": {
    "@fluentui/react-components": "^9.0.0-alpha.36",
    "@popperjs/core": "^2.9.2"
  },
  "resolutions": {
    "**/@fluentui/*/@popperjs/core": "2.8.0"
  }
}

This results in two versions installed:

"@popperjs/core@2.8.0", "@popperjs/core@~2.4.3":
  version "2.8.0"

"@popperjs/core@^2.9.2":
  version "2.9.2"

How do we set this up with syncpack?

Do you mean our repo, correct? Can please expand a bit more there, I did not get the problem.

With syncpack you're only allowed to depend on one semver spec for a given dep, unless you set up a versionGroups entry allowing certain packages to use a different version spec for that dep.

How do we guarantee that yarn resolves the production dep to the same version as the dev dep within our repo?

IMO we should not guarantee this, for example: we don't restrict people to use the same version of React as in our repo, why it should be different for other dependencies? It means that we should be accurate in choosing dependencies, they should follow semver.

I meant within our repo, not from a customer standpoint. Yarn may sometimes decide to resolve foo@^1.0.0 (production dep) and foo@1.1.0 (dev dep) differently, resulting in duplicates within our build process, which is a significant part of the problem @Hotell was trying to resolve to begin with.

The resolutions suggestion was also meant to be used within our repo. (If it doesn't work as I wrote it, we could do some more experimenting.)

@ecraig12345 so this thread is related only to our repo correct?

With syncpack you're only allowed to depend on one semver spec for a given dep, unless you set up a versionGroups entry allowing certain packages to use a different version spec for that dep.

As I know @Hotell proposed to move out all dev dependencies to the root package.json. If we will do this and ignore the root package.json in syncpack, will it solve the issue?

Yarn may sometimes decide to resolve foo@^1.0.0 (production dep) and foo@1.1.0 (dev dep) differently, resulting in duplicates within our build process, which is a significant part of the problem @Hotell was trying to resolve to begin with.

Honestly I don't think that I understand what solves usage of exact versions for dev dependencies.

• we are sure that we are using an exact version, for example webpack@5.0.0
• it does not solve duplicate dependencies as storybook may depend on webpack@^5.1.0
• this results in two entries for webpack (and potentially its sub dependencies) in our yarn.lock

Are these statements correct?

By "this idea" do you mean the VERSIONS file? How would that work from a consumer's perspective, specifically re: legal? (Feel free to respond on teams if needed.)